feat(ai): improve blocklist feedback, pr context reuse, and evals by dancer · Pull Request #169 · tigent/app

dancer · 2026-03-09T18:56:57Z

summary

add blocklist-aware maintainer feedback with explicit refusal replies and comment reactions
store and reuse pr summaries during later feedback and explanation flows
expand the local eval suite with numbered json cases and runtime feedback coverage
add repo-local memory, verified learning, and blocklist enforcement improvements
improve the operator console, config workspace, and docs around the blocklist-first model

vercel · 2026-03-09T18:57:02Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
tigent	Ready	Preview, Comment	Mar 9, 2026 9:20pm

dancer · 2026-03-09T19:21:39Z

@tigent why did you add codex label?

tigent · 2026-03-09T19:21:54Z

labels: feature, ai/mcp, maintenance

feature: The title starts with 'feat' and the body describes new capabilities and improvements, indicating a new feature development.
ai/mcp: The issue frequently mentions 'blocklist-aware feedback', 'blocklist enforcement', and 'blocklist-first model', which are strongly related to model control and routing protocols found in the @ai-sdk/mcp package.
maintenance: Items like 'pr context reuse' and 'expand the local eval suite' refer to improvements in development tooling, testing infrastructure, and internal processes.

dancer · 2026-03-09T19:22:07Z

after this pr merges we can see this improve above @gr2m @felixarntz

app/api/webhook/feedback.ts

app/lib/model.ts

eval/cases/issues/12670.json

eval/cases/13017.json

felixarntz · 2026-03-09T19:39:09Z

.github/tigent.yml

-  the ai sdk is a monorepo with packages for core ai functionality, ui hooks, provider integrations, mcp, gateway, and more. most issues come from users who need help, not from actual bugs.
+  the ai sdk is a monorepo. most issues come from users who need help, not confirmed sdk defects.
+
+  when in doubt, add support. if someone says "doesn't work" or "how do i" but has not shown a clear sdk defect, prefer support over bug.


this makes sense to me; should we maybe clarify that they should ideally be mutually exclusive? or do we want to keep a confirmed bug also be a support issue because it started as such?

I kind of like the idea that support is only used until a problem has been confirmed - or otherwise the issue is closed because it was indeed just support.

felixarntz · 2026-03-09T19:39:25Z

eval/cases/issues/13055.json

+		"bug",
+		"reproduction needed",
+		"ai/provider",
+		"support",


see above - here we have both bug and support in the golden result - I wonder if we want that

not 100% sure on this i'll cc in @gr2m but good shout

eval/cases/13090.json

eval/cases/prs/13090.json

app/api/webhook/feedback.ts

eval/cases/prs/13245.json

dancer added 2 commits March 9, 2026 18:46

feat: improve triage memory and operator console

8a51d8e

fix: tighten blocked feedback and pr context

4ac9f71

tigent bot added codex documentation Improvements or additions to documentation feature New feature or request labels Mar 9, 2026

vercel bot deployed to Preview March 9, 2026 18:57 View deployment

dancer removed the codex label Mar 9, 2026

tigent deleted a comment from tigent bot Mar 9, 2026

fix: refine blocked feedback replies

30e407e